REMARKS 



Claims 1-39 and 41-47 were pending in the application. Claims 41 and 46 have been 
amended. Accordingly, claims 1-39 and 41-47 remain pending in the application. 

35 U.S.C. § 102 Rejections 

Claims 1-5, 7-9, 11-12, 14-21, 23-25, 27-38, 41-42, and 44-47 were rejected under 35 
U.S.C. 102(a) as being anticipated by Solomon et al. (USPN 6151659). Applicant respectfully 
traverses this rejection. 

Solomon teaches a distributed RAID storage system. More specifically, Solomon 
teaches, 

"In the RAID 5 context (hereinafter simply RAID), a longitudinal redundancy 
checking (LRC) is implemented to assure the integrity of data being written from 
a processor to a disk, and being read back from the disk on a host read request. To 
implement LRC, a portion of each disk sector is used to store a calculated LRC 
code for each data sector within the stripe. For the purposes of this specification 
and claims that follow, this LRC code is defined to be the "validation stamp ."" 
(Solomon, Column 6 Lines 1-9) (Emphasis added) 

"At the start of the write transaction 300, the data to be written is transferred from 
the host 302 over the private communication link to the processing node. During a 
normal write mode 304, when all drives are functional, a protected write lock is 
acquired 306, and then the old data and old parity data is read 308 . The location 
and extent of the impending write operation is then stored in NVRAM 310, and 
the validation stamp for the new data is updated 312 . The new data is written 
314 and the old validation stamp of the parity data is compared 316 with the old 
validation stamp of the old data . If the validations match, the old data, new data 
and old parity are XOR'd together 318, and the validation stamp for the new parity 
is updated to reflect the new data 320. The new parity is then written 322 and the 
lock is released 324. The operation is then removed from NVRAM 326 and a 
good status signal is returned 327 to indicate write success. If the validations did 
not match, the old data is read from all of the other data drives 328, and XOR'd 
330 with the new data to be written. The validation stamp for the new parity is 
updated 320. The new parity is then written 322 and the lock is released 324. The 
operation is then removed from NVRAM 326 and a good status signal is returned 
326 to the host to indicate write success." (Solomon, Column 6 Line 64 - Column 
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7 Line 18) (Emphasis added) 

Applicant respectfully submits that Solomon fails to teach or suggest "said storage 
controller is further configured to initialize a given stripe in response to receiving a write request 
to write a new data block at a particular location of said given stripe and detecting a mismatch 
in block verification information associated with an existing data block at the particular 
location of said given stripe to be updated " as recited in claim 1 . The Examiner contends that 
Column 6 Line 64 - Column 7 Line 18 of Solomon teaches this feature. Applicant strongly 
disagrees with the Examiner's assertion. As noted above, while Solomon teaches that during a 
write transaction the old data and the old parity are read, the validation stamp of the new data is 
updated, the new data is written, and then the LRC (validation stamp) of the parity data is 
compared with the LRC of the old data , Solomon does not teach or suggest initializing "a 
given stripe in response to... detecting a mismatch in block verification information 
associated with an existing data block at the particular location of said given stripe to be 
updated " as recited in claim 1 . 

In accordance, independent claim 1 is believed to patentably distinguish over Solomon. 
Claims 2-5, 7-9, 11-12, and 14-16 depend on claim 1 and are therefore believed to patentably 
distinguish over Solomon for at least the reasons given above. 

Likewise, independent claims 27 and 32 recite features similar to those highlighted above 
with regard to independent claim 1 and are therefore believed to patentably distinguish over 
Solomon for at least the reasons given above. Claims 28-31 and claims 33-39 depend on claim 27 
and claim 32, respectively, and are therefore believed to patentably distinguish over Solomon for at 
least the same reasons. 

Additionally, Applicant respectfully submits that Solomon fails to teach or suggest "said 
storage controller is further configured to initialize a given stripe in response to receiving a write 
request to write a new data block at a particular location of said given stripe and detecting a 
mismatch in block verification information in each of at least two existing data blocks of said 

13 



given stripe , wherein one of the two existing data blocks is at the particular location of said 
given stripe to be updated " as recited in claim 17. The Examiner contends that Column 6 Line 64 - 
Column 7 Line 18 of Solomon teaches this feature. Applicant strongly disagrees with the 
Examiner's assertion. As noted above, while Solomon teaches that during a write transaction the 
old data and the old parity are read, the validation stamp of the new data is updated, the new data is 
written, and then the LRC of the parity data is compared with the LRC of the old data , Solomon 
does not teach or suggest initializing "a given stripe in response to... detecting a mismatch in 
block verification information in each of at least two existing data blocks of said given stripe, 
wherein one of the two existing data blocks is at the particular location of said given stripe to 
be updated" as recited in claim 1 7. 

In accordance, independent claim 17 is believed to patentably distinguish over Solomon. 
Claims 18-21 and 23-25 depend on claim 17 and are therefore believed to patentably distinguish 
over Solomon for at least the same reasons. 

Also, Applicant respectfully submits that Solomon fails to teach or suggest " in response 
to receiving the write request, reading an existing data block at the particular location of said 
given stripe to be updated ; and initializing said given stripe in response to detecting a 
mismatch in block verification information associated with the existing data block " as recited 
in claim 47. The Examiner contends that Column 6 Line 64 - Column 7 Line 18 of Solomon 
teaches this feature. Applicant strongly disagrees with the Examiner's assertion. As noted 
above, while Solomon teaches that during a write transaction both the old data and the old parity 
are read, Solomon does not teach or suggest that "in response to receiving the write request, 
reading an existing data block at the particular location of said given stripe to be updated" 
as recited in claim 47. Also, while Solomon teaches that during a write transaction the old data 
and the old parity are read, the validation stamp of the new data is updated, the new data is 
written, and then the LRC of the parity data is compared with the LRC of the old data , 
Solomon does not teach or suggest "initializing said given stripe in response to detecting a 
mismatch in block verification information associated with the existing data block" as 
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recited in claim 47. In accordance, independent claim 47 is believed to patentably distinguish 
over Solomon. 

Furthermore, after considering the arguments presented below in the section 
corresponding to claims 7, 8, 23, 24, 31, 36, 37, 38, 41, 42, 45, and 46, Applicant respectfully 
requests the Examiner to show support for the Examiner's assertion that claims 7, 8, 23, 24, 31, 
36, 37, 38, 41, 42, 45, and 46 are unpatentable over Solomon. 

Applicant respectfully submits that Solomon fails to teach or suggest "wherein said 
storage controller is configured to detect a mismatch in said block verification information by 
comparing a value contained in a field of said particular data block for storing said error 
detection code to a recomputed error detection code computed from data within said particular 
data block read from one of said storage devices" as recited in claim 7. The Examiner contends 
that Column 6 Line 64 - Column 7 Line 18 of Solomon teaches this feature. Applicant strongly 
disagrees with the Examiner's assertion. As noted above, while Solomon teaches that during a 
write transaction the old data and the old parity are read, the validation stamp of the new data is 
updated, the new data is written, and then the LRC of the parity data is compared with the LRC 
of the old data , Solomon does not teach or suggest the features of claim 7 highlighted above. In 
accordance, claim 7 is believed to patentably distinguish over Solomon. Likewise, claims 23 and 
38 recite features similar to those highlighted above with regard to claim 7 and are therefore 
believed to patentably distinguish over Solomon for at least the same reasons. 

Also, Applicant respectfully submits that Solomon fails to teach or suggest "wherein said 
block verification information associated with a particular data block includes an address 
associated with said particular data block " as recited in claim 8. The Examiner contends that 
Column 6 Line 64 - Column 7 Line 18 of Solomon teaches this feature. Applicant strongly 
disagrees with the Examiner's assertion. While Solomon teaches that "the location and extent of 
the impending write operation is then stored in NVRAM 310" (Column 7, Lines 2-3), Solomon 
does not teach or suggest the features of claim 8 highlighted above. In accordance, claim 8 is 
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believed to patentably distinguish over Solomon. Likewise, claims 24, 31, 36 and 37 recite 
features similar to those highlighted above with regard to claim 8 and are therefore believed to 
patentably distinguish over Solomon for at least the same reasons. 

In addition, Applicant respectfully submits that Solomon fails to teach or suggest 
"wherein in response to receiving the write request, said storage controller is configured to read 
the existing data block and a corresponding block verification information, wherein said storage 
controller is also configured to generate a recomputed block verification information from data 
within the existing data block, wherein said storage controller is configured to compare the 
corresponding block verification information to the recomputed block verification information to 
determine whether a mismatch exists in the block verification information associated with the 
existing data block " as recited in claim 41. As noted above, while Solomon teaches that during a 
write transaction the old data and the old parity are read , the validation stamp of the new data is 
updated, the new data is written, and then the LRC of the parity data is compared with the LRC 
of the old data , Solomon does not teach or suggest the features of claim 41 highlighted above. 
In accordance, claim 41 is believed to patentably distinguish over Solomon. 

Furthermore, Applicant respectfully submits that Solomon fails to teach or suggest 
"wherein said storage controller is configured to initialize said given stripe by generating the 
corresponding redundancy data block for said given stripe based on the new data block and a 
known data pattern to be written to said given stripe at memory locations corresponding to one 
or more remaining data blocks of said given stripe " as recited in claim 42. The Examiner 
contends that Column 6 Line 64 - Column 7 Line 18 of Solomon teaches this feature. Applicant 
strongly disagrees with the Examiner's assertion. As noted above, while Solomon teaches that 
during a write transaction the old data and the old parity are read, the validation stamp of the new 
data is updated, the new data is written , and then the LRC of the parity data is compared with 
the LRC of the old data, Solomon does not teach or suggest the features of claim 42 highlighted 
above. In accordance, claim 42 is believed to patentably distinguish over Solomon. 
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Additionally, Applicant respectfully submits that Solomon fails to teach or suggest 
"wherein said storage controller is configured to initialize one or more stripes in said data storage 
subsystem depending upon whether write requests are received that correspond to the one or 
more stripes and depending upon whether a mismatch is detected in the block verification 
information associated with each of the one or more stripes " as recited in claim 45. The 
Examiner again contends that Column 6 Line 64 - Column 7 Line 18 of Solomon teaches this 
feature. Applicant strongly disagrees with the Examiner's assertion. As noted above, while 
Solomon teaches that during a write transaction the old data and the old parity are read , the 
validation stamp of the new data is updated, the new data is written , and then the LRC of the 
parity data is compared with the LRC of the old data , Solomon does not teach or suggest the 
features of claim 45 highlighted above. In accordance, claim 45 is believed to patentably 
distinguish over Solomon. 

Likewise, Applicant respectfully submits that Solomon fails to teach or suggest "wherein 
said storage controller is configured to initialize a subset of said stripes in said data storage 
subsystem in response to receiving a write request to write a new data block in each of the subset 
of said stripes and in response to detecting a mismatch in block verification information 
associated with each of the subset of said stripes , and subsequent to initializing the subset of said 
stripes, initializing one or more remaining stripes in said data storage subsystem in response to 
receiving a write request to write a new data block in each of the one or more remaining stripes 
and in response to detecting a mismatch in block verification information associated with each 
of the one or more remaining stripes " as recited in claim 46. As noted above, while Solomon 
teaches that during a write transaction the old data and the old parity are read , the validation 
stamp of the new data is updated, the new data is written , and then the LRC of the parity data is 
compared with the LRC of the old data , Solomon does not teach or suggest the features of claim 
46 highlighted above. In accordance, claim 46 is believed to patentably distinguish over 
Solomon. 

Applicant respectfully requests the Examiner to show support for the Examiner's 
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argument that claims 7, 8, 23, 24, 31, 36, 37, 38, 41, 42, 45, and 46 are unpatentable over 
Solomon. 

35 U.S.C. § 103 Rejections 

Claims 10, 26, and 39 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Solomon in view of IBM. Applicant respectfully traverses the rejection. Claim 10, claim 26, 
and claim 39 are dependent upon claim 1, claim 17, and claim 32, respectively, and are therefore 
believed to patentably distinguish over cited references for at least the reasons given in the above 
paragraphs discussing claims 1,17, and 32. 

Claims 6, 13, and 22 were rejected under 35 U.S.C. §103(a) as being unpatentable over 
Solomon in view of Archibald, Jr. et al. (US Publication Number 20020169995). Applicant 
respectfully traverses the rejection. Claims 6 and 13 and claim 22 are dependent upon claim 1 
and claim 17, respectively, and are therefore believed to patentably distinguish over cited 
references for at least the reasons given in the above paragraphs discussing claims 1 and 17. 
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CONCLUSION 



In light of the foregoing amendments and remarks, Applicant submits that all pending 
claims are now in condition for allowance, and an early notice to that effect is earnestly solicited. 
If a phone interview would speed allowance of any pending claims, such is requested at the 
Examiner's convenience. 

If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the above 
referenced application(s) from becoming abandoned, Applicant(s) hereby petition for such 
extensions. If any fees are due, the Commissioner is authorized to charge said fees to Meyertons, 
Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501 505/518 1-77800/BNK. 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 
P.O. Box 398 

Austin, Texas 78767-0398 
Phone: (512) 853-8800 
Date:__3_ £L 2^_£r' 



Respectfully submitted, 




B. Noel Kivlin 
Reg. No. 33,929 

ATTORNEY FOR APPLICANT(S) 
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